I. 前言：模式解決的是「不要全塞進一個 Prompt」

昨天釐清了什麼時候該用 Agent。今天處理下一個問題：確定要用 Agent 之後，內部該怎麼組織？

多數人的第一版 Agent 長得都很像 —— 一個 Agent、一份很長的 instruction、一大堆工具。這在功能少的時候完全可行，但隨著範圍擴大，會遇到三個相當一致的症狀：

• 工具選錯的機率上升。 二十個工具擺在一起，相似的那幾個會互相干擾。
• instruction 越寫越長。 每加一個場景就補一段規則，最後沒有人敢動它。
• 無法定位問題。 出錯了，但不知道是理解錯、選錯工具，還是參數填錯。

設計模式的價值就在這裡：它把單一龐大的 Prompt 拆成結構。 而結構的好處不只是可維護，更重要的是可以分別量測 —— 這一點在有了 Day 12 至 Day 14 的評測體系之後，價值會特別明顯。

以下的內容，會逐一說明四個核心模式的結構、什麼時候該用、代價是什麼，以及在 Google ADK 裡怎麼實作。

II. 四個核心模式

先給一張全景。四個模式解決的是不同層面的問題：

注意每一個都有代價。 模式不是免費的優化，它們用成本或延遲換取品質與可維護性。

III. Router Pattern：先分流，再處理

結構

用一個輕量、快速的模型當入口分類器，判斷使用者的意圖屬於哪一類，再路由到專屬的 Agent。

使用者輸入
   ↓
[Router]  這是假單問題、員工問題、還是排程問題？
   ↓
┌──────────┬──────────┬──────────┐
│ 假單 Agent │ 員工 Agent │ 排程 Agent │
│ 3 個工具   │ 3 個工具   │ 3 個工具   │
└──────────┴──────────┴──────────┘

為什麼有效

每個子 Agent 只看得到自己需要的工具。 這帶來兩個直接的好處：

• 上下文變短。 九個工具的 schema 變成三個，省下的 token 每次請求都在省。
• 選錯的機率下降。 模型不會在 search_leaves 與 list_employees 之間混淆，因為後者根本不在清單裡。

這其實就是 Day 10 用 tool_filter 做權限分離的同一個原理，只是動機從「安全」換成了「準確率與成本」。

代價與風險

Router 是單點失效。 分類錯了，後面全錯 —— 而且錯得很難察覺，因為子 Agent 會在自己的工具範圍內努力回答一個它其實不該接的問題。

實務上的緩解方式：

• 給 Router 一個明確的 fallback 類別，不確定時交給一個工具比較完整的通用 Agent。
• 把 Router 的分類結果記錄下來（Day 11 的 on_event），定期檢查分類分布是否合理。

在 Google ADK 裡

兩種做法。用 sub-agent 委派，讓模型自己決定轉交：

from google.adk.agents import Agent

leave_agent = Agent(name="leave_agent", tools=[...], description="處理假單查詢與狀態更新")
roster_agent = Agent(name="roster_agent", tools=[...], description="處理員工清單與職務代理")

router = Agent(
    name="leave_router",
    instruction="根據使用者的問題，轉交給合適的專責 agent。",
    sub_agents=[leave_agent, roster_agent],
)

description 在這裡是關鍵欄位，不是註解。 Router 就是靠各個 sub-agent 的 description 決定要轉交給誰 —— 寫得含糊，分類就會不準。這與 Day 3 說的「Docstring 是進入模型上下文的 Prompt」是同一件事。

或者用 Workflow 把路由寫成明確的邊，讓分類由程式碼決定 —— 這在分類規則明確時更可靠，也符合 Day 25 的原則。

IV. Orchestrator-Workers：拆解與並行

結構

中央協調者把大任務拆成多個獨立子任務，分派給 Worker 並行執行，最後彙整。

[Orchestrator]  「巡檢全部三十台伺服器」
   ↓ 拆解
┌────────┬────────┬────────┐
│Worker 1│Worker 2│Worker 3│   ← 並行
└────────┴────────┴────────┘
   ↓ 彙整
[Orchestrator]  產出總結報告

適用的前提

這個模式有一個容易被忽略的前提：子任務必須真的獨立。

如果 Worker 2 需要 Worker 1 的結果才能開始，那就不是並行，而是一條偽裝成並行的序列 —— 而且還多付了協調成本。

判斷方式：把子任務的順序打亂，結果會不會變？ 不會變，才適合並行。

代價

• 協調本身有成本。 拆解要一次模型呼叫，彙整又要一次。子任務少的時候，這兩次的開銷可能超過並行省下的時間。
• 結果要能合併。 三十份巡檢報告合成一份總結，那個「合成」步驟本身可能就是上下文的瓶頸。

在 Google ADK 裡

ParallelAgent 是最直接的對應：

from google.adk.agents import ParallelAgent, SequentialAgent

check_all = ParallelAgent(
    name="check_all_hosts",
    sub_agents=[check_web, check_db, check_cache],
)

pipeline = SequentialAgent(
    name="inspection_pipeline",
    sub_agents=[check_all, summarize_agent],
)

或用 Workflow 描述更複雜的圖，它支援 JoinNode 來處理多路匯流，並提供 max_concurrency 控制並行度。

V. Evaluator-Optimizer：生成、審查、重來

結構

Generator 產出初版，Evaluator 嚴格審查；未達標就附上具體的修改意見退回，直到通過或達到上限。

[Generator] → 初版
   ↓
[Evaluator] → 通過？ → 輸出
   ↓ 不通過（附具體意見）
[Generator] → 修訂版 → 回到 Evaluator

為什麼這個模式特別有效

因為審查比生成容易。

要模型「一次寫出完全正確的 SQL」很難；但要它「檢查這段 SQL 有沒有漏掉 WHERE 條件」相對容易得多。把兩件事分開，各自都落在模型比較擅長的區間裡。

這也是為什麼 Evaluator 的意見必須具體。回一句「不夠好」沒有任何價值；回「缺少對 deleted_at IS NULL 的過濾」才能驅動下一輪修正。

這跟 Day 3 那個設計是同一個原理 —— 當時把工具的錯誤訊息寫成「下一個合法狀態為 submitted」，而不是「狀態不合法」。可執行的回饋才有價值。

代價

每一輪都是一次完整的生成加一次完整的審查。 三輪就是六次模型呼叫。這個模式的成本相當高，只適合用在輸出品質的價值足以覆蓋成本的場景。

而且它需要一個明確的終止條件：達標即停、或最多 N 輪。少了它，這個模式會變成一個很貴的無限迴圈。

在 Google ADK 裡

LoopAgent 就是為此設計的 —— 子 agent 用 escalate 跳出迴圈：

from google.adk.agents import LoopAgent

refine = LoopAgent(
    name="sql_refiner",
    sub_agents=[generator_agent, evaluator_agent],
    max_iterations=3,          # 終止條件，不能省
)

Evaluator 判定通過時，在 event 的 actions.escalate 設為 True，迴圈就會結束 —— 這正是 Day 11 提過的那個欄位。

VI. Parallelization & Voting：用多數決壓住隨機性

結構

同一個問題，並行送給多個實例（不同溫度、不同 prompt、甚至不同模型），最後投票或由裁判挑選。

什麼時候值得

當單次結果的不可靠是主要問題時。

Day 11 提過一件事：模型是非確定性的，同一句話跑十次可能有三種結果。多數決正是直接針對這個問題 —— 三次裡有兩次一致，可信度就比單次高得多。

但要注意它的邊界：多數決只能壓住隨機性，壓不住系統性錯誤。 如果模型是「一貫地」把 employee_id 寫成 assignee，那跑十次會得到十個一樣的錯誤答案。

這正是為什麼 Day 15 至 Day 20 的微調不能被多數決取代。 難點 ④ 是系統性的，投票救不了。

代價

成本直接乘上並行數。 三路投票就是三倍的 token 費用。加上裁判的話是三倍多一點。

一個更省的變體

不必每次都投票。可以先跑一次，只在信心不足時才展開並行 —— 例如模型的回應包含猶豫的措辭、或是工具參數落在邊界值附近。

VII. 這四個模式其實可以疊起來

實務上很少只用一個。一個成熟的差勤系統可能長這樣：

[Router]         判斷是假單、員工還是排程問題
   ↓
[Orchestrator]   假單問題 → 拆成「查詢」與「更新」兩個子任務
   ↓
[Evaluator]      更新前先審查：狀態轉移合法嗎？參數格式對嗎？
   ↓
[Flow]           確認無誤後，由固定腳本執行

注意最後一步又回到了 Flow。 這呼應昨天的結論：模式解決的是 Agent 內部怎麼組織，但真正執行破壞性操作的那一步，仍然應該是可稽核的程式碼。

什麼時候不要用模式

最後一個提醒：這四個模式都有成本，不要預先套用。

從單一 Agent 開始，等到出現具體症狀 —— 工具選錯率高、上下文太長、品質不穩 —— 再針對那個症狀引入對應的模式。

而「出現症狀」這件事需要能被量測，這又回到了 Day 12 至 Day 14 建立的評測體系。沒有數字，套模式就只是憑感覺重構。

VIII. 結語

設計模式不是為了讓架構看起來精緻，而是為了把一個難以維護的大 Prompt，拆成可以分別量測、分別改善的部分。

總結來說，今天有三個重點值得帶走：

• 每個模式都有明確的代價，而且不是小數目： Router 多一次呼叫且是單點失效、Evaluator-Optimizer 每輪成本翻倍、Parallelization 成本直接乘上並行數。先確認症狀存在、再引入對應模式，不要預先套用。
• Evaluator 的意見必須具體，否則整個模式失效： 「不夠好」驅動不了修正，「缺少 deleted_at IS NULL 過濾」才可以。這與 Day 3 把錯誤訊息寫成「下一個合法狀態為 submitted」是同一個原理 —— 可執行的回饋才有價值。
• 多數決壓得住隨機性，壓不住系統性錯誤： 如果模型一貫地把參數名寫錯，投票十次會得到十個相同的錯誤。這正是難點 ④ 必須靠微調而非投票解決的原因，也劃出了這個模式的邊界。

明天要換一個視角。這一整套 Agent 的概念 —— Agent、Tool、Memory、Orchestrator —— 對一個有經驗的軟體工程師來說，其實都能在既有的知識裡找到對照。明天要做的就是這場概念大對照。

參考來源

• Anthropic・Building effective agents——Routing、Orchestrator-workers、Evaluator-optimizer、Parallelization 的定義
• google/adk/agents/__init__.py（google-adk 2.7.1）——SequentialAgent / ParallelAgent / LoopAgent
• google/adk/workflow/__init__.py——Workflow、JoinNode、max_concurrency
• google/adk/events/event_actions.py——escalate 欄位與 LoopAgent 的終止機制
• Google ADK・LLM Agents——sub_agents 與 description 在委派決策中的角色

查證日期：2026-08-24

I am Simon

大家好，我是 Simon 劉育維，是一位 AI 領域解決方案專家，目前也擔任 Google Cloud AI 領域開發者專家 (GDE)，期待能夠幫助企業導入人工智慧相關技術解決問題。如果這篇文章對您有幫助，歡迎在我的 Linkedin 上留言提供意見，並與我一起討論有關人工智慧的主題，期待能夠對大家有所幫助！

我的個人部落格資訊：https://medium.com/@simon3458